Re: access(2)--a security hole?
Julian Assange (proff@suburbia.apana.org.au)
Sat, 22 Oct 1994 01:50:59 +0000
Access(2) is inhern
On Fri, 21 Oct 1994, Justin Mason wrote:
> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> >the FreeBSD man page for access(2) includes a section titled "CAVEAT"
> >which says that "Access() is a potential security hole and should never
> >be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.
>
>
On Fri, 21 Oct 1994, Justin Mason wrote:
> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> >the FreeBSD man page for access(2) includes a section titled "CAVEAT"
> >which says that "Access() is a potential security hole and should never
> >be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.
>
>
On Fri, 21 Oct 1994, Justin Mason wrote:
> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> >the FreeBSD man page for access(2) includes a section titled "CAVEAT"
> >which says that "Access() is a potential security hole and should never
> >be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.
>
>
On Fri, 21 Oct 1994, Justin Mason wrote:
> In your message of Thu, 20 Oct 1994 21:41:48 BST, you say:
>
> >the FreeBSD man page for access(2) includes a section titled "CAVEAT"
> >which says that "Access() is a potential security hole and should never
> >be used."
>
> hmmm..... access(2) uses the REAL uid, not the EFFECTIVE uid when
> testing permissions. The idea is that, when you write a setuid program,
> you can check to see if the user has permission to access a file while
> you have euid==root. Eg.
>
> real uid = user
> eff uid = root
>
> The problem I found with using access is that it's actually easier
> just to flip real and effective uids, test writability, open the file, etc.
> then flip the uids back. If you use normal code, you only have to
> worry about the effective uid; however, if you use access(), you have
> to worry about both real and eff uid.
>
> Actually, that's not really a security hole, just additional complexity.
> Maybe access() on FreeBSD is a different matter. At least, the access
> manpages on sunos and solaris don't mention any holes...
>
> --j.
>
>
Acess(2)/(3) is inherently insecure because its argument is a file-name
not
a file descriptor, meaning its vulnerable to race conditions, which mean
that a link or file with different permissions could be implanted over
the file that access passed.
Proff